В этот раз мы рассмотрим сразу две функции Enable-VMHostSSH/Disable-VMHostSSH моего PowerCLI модуля для управления виртуальной инфраструктурой VMware Vi-Module.psm1. Очень часто администраторам виртуальной инфраструктуры требуется временно включить SSH на хосте/хостах ESXi, например, для запуска esxtop или для выяснения причин PSOD или для решения проблем с СХД...

В преддверии глобального анонса продуктов и технологий на 2016 год, компания VMware опубликовала несколько новостей о новых продуктах, в частности о решении для виртуализации пользовательских окружений VMware Horizon 7.

Давайте детально посмотрим на новые возможности, которые нам обещают в Horizon 7 в рамках анонса:

1. Полноценное использование технологии Instant Clone Technology.

Мы уже писали об этой технологии, которая позволяет "на лету" создать клон виртуальной машины, а следовательно практически мгновенно развернуть новый виртуальный ПК, каждый из которых будет использовать данные базовой машины (общая память на чтение). В сочетании с технологией доставки приложений через подключаемые виртуальные диски VMware App Volumes 3.0 и средством управления окружениями User Environment Manager, эти возможности позволят пользователям мгновенный доступ к своим данным, при этом рабочая машина пользователя не будет "загрязняться" ненужными устанавливаемыми программами и ключами реестра.

Приложения уже будут поступать в машину виртуализованными, упакованными и готовыми к использованию, а пользователь всегда может отключить их или подключить новые сервисы. И все это будет работать быстро, так как в силу технологии App Volumes винда не будет стареть и тормозить, а сами десктопы будут доступны к использованию мгновенно. Достигаться это будет посредством того, что при отключении пользователя его десктоп будет уничтожаться, а при подключении - на лету собираться средствами Instant Clone и App Volumes.

Десктоп пользователя = (мгновенный клон родительской ВМ) + (корпоративные приложения на дисках App Volumes) + (данные пользователя) + (установленные пользователем приложения)

Патчинг приложений теперь выглядит совершенно по-иному - теперь можно обновлять их в рамках App Volumes, а пользователь получает обновленное приложение уже при следующем логине. Ну и теперь никаких Boot Storms при одновременном логине пользователей - ведь десктопы всегда включены.

Все это будет возможно на Virtual Hardware версии 11. Пока будут поддерживаться только плавающие (floating) пулы виртуальных ПК, но в следующей версии будут поддерживаться и dedicated-десктопы. Ну и NVIDIA GRID пока для таких десктопов поддерживаться не будет.

2. Умные политики для устройств пользователей в зависимости от условий логина.

В инфраструктуре виртуальных ПК администраторы и менеджеры информационной безопасности больше всего волнуются о соблюдении требований, касающихся защиты конечных устройств (см. нашу статью о том, как украсть виртуальную машину).

Теперь в VMware Horizon View 7 появляются "умные политики" (Smart Policies), которые позволяют в зависимости от способа логина пользователя применять те или иные правила. Например, пользователю, который логинится через сеть разумно отключить копирование на USB-устройство, перенаправление клавиатуры и возможность печати. Также можно, например, кастомизировать полосу пропускания по протоколу PCoIP, в зависимости от типа логина пользователя.

Обзор функции Smart Policies:

Также Identity manager обеспечивает простоту логина уже аутентифицированного пользователя к любым выбранным объектам своего окружения посредством генерации временных сертификатов при запросе объектов пользователем.

3. Улучшения доступа к консоли машины для мобильных устройств и протокол Blast Extreme.

Теперь технология веб-доступа к консоли виртуальной машины Blast Extreme полноценно включена в стек протоколов доступа вместе с PCoIP и RDP. С помощью этой технологии можно иметь быстро работающее устройство с консолью виртуального ПК на разрешении до 4К. Blast Extreme заточена под мобильные устройства, что выражается в том, например, что сам протокол заботится об уменьшении нагрузки на CPU и более долгой жизни батареи.

Также Blast Extreme теперь оптимизирован для нагрузок в виртуальных ПК, которые используют технологию NVIDIA GRID (поддерживаются карточки K1, K2, M6 и M60). Поскольку в среде NVIDIA GRID большая часть нагрузки CPU ложится на плечи vGPU, то это позволяет достичь синергичного эффекта для технологии Blast Extreme. Все это вместе дает до 18% больше пользователей на сервере, увеличение на 6-13% фреймрейта, уменьшение latency на величину до 51 мс, а также снижение требований к пропускной способности канала на 48-89%. Если это все так, то это супер-круто. О подробностях можно прочитать в блоге NVIDIA.

4. Возможности Horizon Access Point.

Это альтернатива Security Server в VMware View, которая позволяет защитить инфраструктуру VMware Horizon View при доступе извне. Может быть настроен для протоколов RADIUS или RSA SecurID:

5. Поддержка режима vSGA для адаптеров AMD.

Вслед за поддержкой технологий NVIDIA, компания VMware постепенно наращивает поддержку адаптеров AMD. Сейчас для них будет поддерживаться режим vSGA:

Будет обеспечена поддержка технологии AMD SR-IOV (single root I/O virtualization), нативных драйверов AMD для аппаратного ускорения OpenGL, DirectX и OpenCL. Кроме того, обещают сертификацию для приложений Solidworks, PTC и Siemens.

6. Превью технологии Flash Redirection.

Эта технология позволяет перенаправить flash-контент на конечное устройство пользователя и там уже рендерить его. Пока данная технология доступна в статусе Tech Preview.

7. Поддержка Intel vDGA Graphics с последними процессорами Intel Xeon E3.

Теперь для режима прямого проброса vDGA поддерживаются интегрированные модули Iris Pro GPU совместно с технологией Intel Graphics Virtualization Technology (Intel GVT-d).

8. Улучшения печати и Windows 10.

Теперь печать из виртуального ПК работает до 4 раз быстрее, а для Windows 10 улучшена поддержка сканеров и проброса последовательных портов.

9. Функции URL Redirection.

Мы уже писали о Flash URL Redirection, здесь механизм работы такой же. Администратор может задать какие адреса можно открывать локально, внутри виртуального ПК (безопасно), а для каких потребуется запускать браузер на хостовой машине (все остальное).

10. Обновленные клиенты VMware Horizon Client 4.0.

Horizon Client 4.0 Windows:

• Полная поддержка Blast Extreme и аппаратного ускорения.
• Предоставляет масштабируемое разрешение для лучшей читабельности.
• Автошаринг USB-устройств для Client Drive Redirection (улучшено).
• Быстрее работает печать.
• Быстрее работает по сети WAN через Security Server.
• Обновленные OpenSSL и TLS.
• Поддержка работы на Windows Server 2012.

VMware Horizon Client 4.0 Mac:

• Полная поддержка Blast Extreme.
• Работает со сплит-вью в OS X El Capitan.
• Улучшения полноэкранного режима и при работе с несколькими мониторами.
• Открытие локальных файлов через Horizon hosted apps.
• Быстрее работает печать.
• Быстрее работает по сети WAN через Security Server.
• 64-битная версия клиента.
• Запоминание username/domain при логине.
• Обновленные OpenSSL и TLS.

VMware Horizon Linux Client 4.0:

• Поддержка RHEL 7.2 x64 и Ubuntu 14.04 x64.
• Полная поддержка Blast Extreme.
• Быстрее работает печать.
• Быстрее работает по сети WAN через Security Server.
• Режим FIPS для Blast Extreme, PCoIP и USB.

VMware Horizon iOS Client 4.0:

• Split view для iPad Air 2 и iPad Pro.
• Полная поддержка Blast Extreme и аппаратного ускорения.
• Использование Apple Pencil как мышки.
• Real-time Audio при использовании микрофона.
• Улучшенные настройки (доступны в самом клиенте).
• Обновленные OpenSSL и TLS.

VMware Horizon Android Client 4.0:

• Поддержка доступа через Android Fingerprint
• Полная поддержка Blast Extreme и аппаратного ускорения.
• Real-time Audio при использовании микрофона.
• Возможность использования внутреннего хранилища для приложений в виртуальном ПК.
• Обновленные OpenSSL и TLS.

VMware Horizon Chrome OS Client 4.0:

• Полная поддержка Blast Extreme.
• Возможность использования хранилища Google Drive и USB-хранилища для приложений в виртуальном ПК.

HTML Access 4.0:

• Поддержка Linux-десктопов работает на мобильном Safari в iOS.
• Поддержка F5 APM (Access Policy Manager).

11. Улучшения VMware Horizon for Linux.

Тут можно отметить следующие вещи:

• Поддержка SLED 11 SP3.
• Операции copy/paste между Linux-ПК и клиентской ОС.
• Поддержка vGPU для RHEL 7.x (6.2.1).
• Работа SSO для RHEL 6.6 и CentOS 6.6 без смарт-карт (6.2.1).

12. Режим Horizon Air Hybrid mode.

Этот режим предоставляет возможности для построения следующей архитектуры:

• Десктопы и приложения располагаются локально (on-premise).
• Панель управления облачной инфраструктурой доступна как SaaS.

13. Улучшения масштабируемости и гибкости.

Здесь 3 основных моменты:

• Теперь в архитектуре Cloud pod может быть до 10 POD'ов на 4 площадках с числом десктопов до 50 000.
• Cloud pod architecture (CPA) позволяет назначение прав на сайт для вложенных AD security groups.
• Улучшенная поддержка отказоустойчивости - если ресурсы сайта недоступны, пользователь автоматически перенаправляется до другой сайт, где его ждет резервный десктоп.

Как всегда, VMware сделала очень большой шаг вперед в плане инфраструктуры виртуальных ПК, и, как мне кажется, VMware Horizon 7 будет реальным убийцей продукции Citrix. Если даже и не в технологическом плане, то уж в пиар-плане так точно. Ждем доступности продукта в этом году!

Мы часто пишем о веб-консоли для управления отдельными хост-серверами VMware ESXi Embedded Host Client, которая для многих администраторов уже стала инструментом, используемым каждый день. На днях компания VMware выпустила обновленную версию ESXi Embedded Host Client v5, которая доступна для загрузки на сайте проекта VMware Labs.

На самом деле, нового в VMware ESXi Embedded Host Client 5 не так много, но говорят, что было исправлено очень много багов:

Хост-серверы

• Улучшения в разделе мониторинга производительности (ресайз и поведение тултипов).

Виртуальные машины

• Возможность простого экспорта виртуальной машины (базовые функции).
• Поддержка клавиатур IT/ES в браузерной консоли.
• Исправлены серьезные ошибки при операциях с дисковым контроллером (добавление/удаление, назначение дисков и т.п.).

Хранилища

• Исправлена сортировка в datastore browser.

Общие улучшения

• Улучшенное поведение таблиц (включая возможности выбора объектов, колонок и фильтрации).
• Более производительная панель Recent Tasks.
• Улучшенная производительность таблицы виртуальных машин.
• Улучшенное поведение контекстных меню на iPad.
• Возможность перетаскивать и ресайзить окна и диалоги на iPad.
• Множество исправлений ошибок.

Скачать VMware ESXi Embedded Host Client 5 можно по этой ссылке. Кстати, таблица совместимых браузеров:

Какое-то время назад мы писали о функции Data Locality, которая есть в решении для создания отказоустойчивых кластеров VMware Virtual SAN. Каждый раз, когда виртуальная машина читает данные с хранилища, они сохраняются в кэше (Read Cache) на SSD-накопителе, и эти данные могут быть востребованы очень быстро. Но в рамках растянутого кластера (vSphere Stretched Cluster) с высокой скоростью доступа к данным по сети передачи данных, возможно, фича Site / Data Locality вам не понадобится. Вот по какой причине.

Если ваши виртуальные машины часто переезжают с хоста на хост ESXi, при этом сами хосты географически разнесены в рамках VSAN Fault Domains, например, по одному зданию географически, то срабатывает функция Site Locality, которая требует, чтобы кэш на чтение располагался на том же узле/сайте, что и сами дисковые объекты машины. Это отнимает время на прогрев кэша хоста ESXi на новом месте для машины, а вот в скорости в итоге особой прибавки не дает, особенно, если у вас высокоскоростное соединение для всех серверов в рамках здания.

В этом случае Site Locality лучше отключить и не прогревать кэш каждый раз при миграциях в рамкха растянутого кластера с высокой пропускной способностью сети. Сначала запросим значение Site Locality:

[root@esxi-01:~] esxcfg-advcfg -g /VSAN/DOMOwnerForceWarmCache


Value of DOMOwnerForceWarmCache is 0

Устанавливаем значение в 1, если хотим отключить принудительный прогрев кэша при смене площадки размещения машины:

[root@esxi-01:~] esxcfg-advcfg -s 1 /VSAN/DOMOwnerForceWarmCache

Value of DOMOwnerForceWarmCache is 1

Очередная функция Compare-VMHostSoftwareVibмоего PowerCLI-модуля для управления виртуальной инфраструктурой VMware Vi-Module.psm1 поможет вам сравнить установленные VIB-пакеты (vSphere Installation Bundle) между двумя и более хостами ESXi. Функция позволяет сравнивать как два отдельно взятых хоста, так и группу хостов, например, сравнить целый HA/DRS Cluster с эталонным хостом.

С удовольствием представляем вам очередного спонсора VM Guru - компанию AFI Distribution, осуществляющую поставку замечательного продукта для резервного копирования виртуальных машин - Altaro VM Backup.

Altaro VM Backup — простое в использовании решение для резервного копирования, надежного хранения и восстановления виртуальных машин на базе Hyper-V и VMware. Программа имеет легкий и понятный интерфейс, интуитивную настройку, а самое главное - безотказно работает.

15 минут на установку и создание первых копий машин – никаких сложных настроек и установки вспомогательного ПО не требуется. Стоимость не зависит от количества ядер и виртуальных машин: лицензируются только хосты, с которых будет идти резервное копирование машин.

Резервное копирование без остановки виртуальной машины

Копирование «на лету» для виртуальных машин под управлением ОС Windows и Linux, включая машины с MS Exchange и MS SQL на борту.

Создание копий сразу в несколько хранилищ

Altaro VMBackup создаст для вас несколько копий виртуальных машин для надежности, при этом поддерживаются следующие хранилища:

• Носители, подключаемые по USB
• Внешние диски eSATA
• Сетевые папки, доступные по UNC
• NAS-устройства, доступные по UNC
• Локальные жесткие диски (рекомендуется использовать только для тестирования продукта)
• Картриджи RDX
• Внешние сервера, доступные через Интернет/WAN

Автоматическая чистка

Старые копии могут быть автоматически удалены по расписанию, а также после того, как новые копии будут проверены на работоспособность. Время хранения копий на различных хранилищах можно настраивать отдельно.

Шифрование копий на внешних серверах

Вы ведь не хотите, чтобы копию виртуальной машины кто-нибудь утащил с внешнего сервера? Мы позаботились об этом – каждая копия зашифрована надежным алгоритмом AES!

Восстановление машины или ее клона на тот же или любой другой хост

Вы можете восстанавливать копии машин куда угодно – лицензия не требуется! На тот же хост, заменив работающую (утерянную) машину, в виде клона машины, а также на любой другой хост.

Вся ваша сеть видна из единой консоли управления, чтобы вы не тратили в самый ответственный момент ни минуты лишнего времени на выбор хоста для восстановления резервных копий.

Восстановление отдельных файлов и писем из резервной копии

В панель управления встроен проводник по файлам и письмам резервных копий – вы можете восстановить любой элемент всего в пару кликов, моментально!

Периодическая проверка работоспособности копии

Хорошая резервная копия – та, что может быть восстановлена в случае аварии, не так ли? Altaro VMBackup ответственно проверит каждую сделанную копию прежде, чем вам понадобится ею воспользоваться. И когда мы говорим о проверке копии, мы имеет в виду не просто проверку на читаемость и целостность, а самую настоящую проверку на работоспособность в специальном тестовом окружении.

Поддержка на русском языке!

Наши специалисты не только поддержат вас в любых вопросах по телефону и электронной почте, но и с радостью покажут работу продукта «живьем» на наших серверах, а также установят и настроят решение в вашей сети «под ключ» совершенно бесплатно!

Для англоговорящих клиентов доступны чат со специалистом и автоматические рекомендации по устранению проблем прямо из интерфейса Altaro VMBackup.

Скачать решение Altaro VMBackup можно бесплатно по этой ссылке (там же есть и онлайн-демо продукта, попробуйте).

Некоторое время назад мы писали о документе VMware Lifecycle Product Matrix, описывающем жизненный цикл продуктов VMware. В январе 2016 года вышла обновленная версия этого документа:

Напомним основные стадии жизненного цикла продуктов VMware:

• Genetral Availability - официальная доступность продукта для загрузки, с даты которой начинается General Support Phase.
• General Support Phase - эта фаза начинается после выпуска мажорного релиза (GA) и длится определенное время. В этот период пользователи, купившие официальную поддержку VMware (а не купить ее нельзя) получают апдейты и апгрейды, багофиксы и фиксы безопасности, а также техническое сопровождение в соответствии с Terms and Conditions.
• Technical Guidance Phase - эта фаза (если она доступна) начинается с момента окончания предыдущей фазы и длится заданное время. Здесь уже предоставляются инструкции через портал самообслуживания, а по телефону звонки не принимаются. В этой фазе можно открыть кейс в техподдержке онлайн, но только для поддерживаемых конфигураций. В этой фазе VMware не оказывает поддержки, касающейся оборудования, обновлений ОС, патчей безопасности или багофиксов (если о другом не объявлено дополнительно). Предполагается, что в этой фазе пользователи используют стабильные версии ПО и конфигураций при нормальных (не повышенных) нагрузках.
• End of Support Life (EOSL) - в этой фазе продукт уже не поддерживается VMware. Это означает окончание первых двух фаз. Кроме этого, здесь происходит прекращение продаж продукта.
• End of Availability (EOA) / End Of Distribution (EOD) - в этом режиме продукт уже не поддерживается, и он недоступен на сайте VMware, то есть его, попросту говоря, нельзя скачать.

Более подробно обо всем этом - в документе.

Компания VMware в своем блоге, посвященном продуктам линейки VMware vSphere, представила интереснейшее доказательство, что кластер VMware Virtual SAN дает надежность "шесть девяток", то есть доступность данных 99,9999% времени в году. А это меньше, чем 32 секунды простоя в год.

Бесспорно, приведенное ниже "доказательство" основано на множестве допущений, поэтому заявление о шести девятках является несколько популистским. С моей точки зрения, гораздо более вероятно, что админ с бодуна не туда нажмет, или, например, в команде vmkfstools укажет не тот LUN и снесет все виртуальные машины на томе VMFS (привет, Антон!), чем откажет оборудование с дублированием компонентов. Но все же, рассмотрим это доказательство ниже.

Прежде всего, введем 2 понятия:

• AFR – Annualized Failure Rate, то есть вероятность отказа в год (носителя данных или другого компонента), выраженная в процентах.
• MTBF – Mean Time Between Failures (среднее время между отказами). Это время в часах.

Эти 2 величины взаимосвязаны и выражаются одна через другую в соответствии с формулой:

AFR = 1/(MTBF/8760) * 100%

Обычно, как HDD, так и SSD накопители, имеют AFR от 0.87% до 0.44%, что дает от 1 000 000 до 2 000 000 часов MTBF. Далее для примера берут диск 10K HDD от Seagate (популярная модель ST1200MM0088), для которой AFR равен 0.44% (см. вторую страницу даташита) или 2 миллиона часов в понятии MTBF. Ну и взяли популярный SSD Intel 3710 для целей кэширования, который также имеет MTBF на 2 миллиона часов.

Для того, чтобы вычислить время доступности данных на таких накопителях, нужно понимать время, которое необходимо для восстановления бэкапа на новый накопитель в случае сбоя. По консервативным оценкам - это 24 часа. Таким образом, доступность данных будет равна:

2 000 000/ (2 000 000 + 24) = 0,99998

То есть, 4 девятки. Но диск - это еще не весь сервис. Есть еще надежность дискового контроллера, самого хост-сервера и стойки в целом (по питанию). VMware запросила данные у производителей и получила следующие параметры доступности:

• Rack: 0,99998
• Host: 0,9998
• Controller: 0,9996

Итого, мы имеем доступность:

0,99998 (Rack) * 0,9998 (Host) * 0,9996 (Controller) * 0,99998 (SSD Cache) * 0,99998 (SSD/HDD Capacity) = 0,9993

Вот, доступность уже 3 девятки, что эквивалентно 8,76 часов простоя в год. Не так плохо, но это слишком оптимистичные значения - на деле есть прочие факторы, влияющие на доступность, поэтому уберем последнюю цифру из долей для доступности каждого из компонентов:

0,9999 (Rack) * 0,999 (Host) * 0,999 (Controller) * 0,9999 (SSD Cache) * 0,9999 (SSD/HDD Capacity) = 0,997

Получается 2 девятки, а это 3,65 дня простоя в год, что уже довольно критично для многих бизнесов.

Ну а теперь применим технологию VMware Virtual SAN, которая дублирует данные на уровне виртуальных машин и отдельных виртуальных дисков. Если мы используем параметр FTT (Numbers of failures to tolerate) равный 1, что подразумевает хранение одной реплики данных, то вероятность недоступности хранилища Virtual SAN данных будет равна вероятности отказа 2-х хранилищ одновременно, то есть:

(1-0.997)^2 = 0.00000528

Ну а доступность в данном случае равна:

1-0.00000528 = 0.999994

То есть, уже 5 девяток. Но это доступность для одного объекта VSAN, а отдельная виртуальная машина обычно имеет несколько объектов, допустим, 10. Тогда ее доступность будет равна:

0.999994^10 = 0.99994

В итоге, 4 девятки. Это 52,56 минуты простоя в год. В зависимости от того, сколько объектов у вас будет на одну ВМ, вы будете иметь доступность от 4 до 5 девяток.

А теперь возьмем FTT=2, то есть конфигурацию, когда имеется 2 дополнительных копии данных для каждого объекта в кластере Virtual SAN. В этом случае вероятность полного отказа всех трех копий данных:

(1-0.997)^3 = 0.00000001214

А доступность для ВМ с десятью объектами:

0.999999988^10 = 0.999999879

То есть, те самые 6 девяток, о которых говорится на слайде. Конечно, все это допущения, фантазии и игра с вероятностями, но читать это все равно интересно. Еще более интересно то, что оригинал этой статьи написала женщина)

Мы уже не раз касались решения VMware App Volumes (ранее это был продукт Cloud Volumes), предназначенного для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам. Буквально вчера компания VMware анонсировала обновленную версию App Volumes 3.0, где появилось несколько существенных нововведений.

Итак, что именно появилось нового в App Volumes 3.0:

• AppToggle – это технология, предоставляющая возможности установки приложений и безопасного назначения прав (до этого приложения просто прятались) пользователям в рамках одного тома AppStack. Это снижает число необходимых томов для обслуживания, упрощает управление ими и увеличивают производительность. Этот архитектурный подход позволяет приложениям внутри одного AppStack иметь взаимозависимости и расшаривать их между другими приложениями, что дает высокую степень гибкости развертывания инфраструктуры App Volumes.
• AppCapture with AppIsolation – теперь технология AppCapture имеет интерфейс CLI, а также интегрирована с продуктом VMware ThinApp, что позволяет в рамках одного AppStack собирать физически устанавливаемые и виртуализованные приложения для доставки их отдельным пользователям и рабочим группам. Теперь процесс доставки приложений, их обновления и контроля изоляции друг от друга становится весьма простым (например, раньше нужно было запускать ThinApp, а потом отдельно средства AppCapture).
• AppScaling with Multizones – теперь если у вас несколько датацентров, то App Volumes предоставляет средства для развертывания одних и тех же AppStacks на нескольких площадках. Если раньше нужно было вручную заботиться о репликации хранилищ приложений, то теперь App Volumes можно интегрировать с экземплярами vCenter на каждой из площадок и выбрать, куда задеплоить (отреплицировать) нужные AppStacks с приложениями пользователей. Сканирование датасторов в датацентрах на предмет синхронизации AppStacks будет проходить с заданным интервалом времени.
• Integrated Application, User Management and Monitoring Architecture – новая архитектура App Volumes собирает в одном месте функции управления приложениями и их жизненным циклом, окружениями и правами пользователей, а также средства мониторинга инфраструктуры App Volumes. Решение интегрировано с унифицированным средством мониторинга виртуальной инфраструктуры vRealize Operations Manager.
• Unified Administration Console ­– исходня из прошлого пункта, теперь все функции решения собраны в одной консоли администратора (Astro console). Этот администратор настраивает инфраструктуру физических и виртуальных приложений, которая масштабируется на один или несколько датацентров на виртуальных ПК пользователей.

Решение VMware App Volumes 3.0 будет поставляться в трех изданиях:

О доступности VMware App Volumes 3.0 будет объявлено дополнительно.

Компания VMware выпустила очень интересный документ "VMware vSphere 6 Fault Tolerance Architecture and Performance", посвященный производительности технологии VMware Fault Tolerance (FT), которая позволяет обеспечивать непрерывную доступность виртуальных машин, даже в случае отказа хост-сервера VMware ESXi. Делается это за счет техники Fast Checkpointing, по своей сути похожей на комбинацию Storage vMotion и vMotion, которая копирует состояние дисков, памяти, процессорных команд и сетевого трафика на резервную машину, поддерживая ее в полностью синхронизированном с первой состоянии. На данный момент vSphere 6 FT поддерживает виртуальные машины с конфигурацией до 4 vCPU и до 64 ГБ оперативной памяти на хост ESXi.

Давайте посмотрим на интереснейшие результаты тестирования производительности, приведенные в документе.

1. Процедура компиляции ядра в гостевой ОС.

Эта процедура грузит CPU на 100%, поэтому посмотрим, каковы тут потери, связанные с аспектами производительности процессора и синхронной передачи команд. Все вполне хорошо, потери небольшие:

2. Сетевая активность.

Если говорить о производительности сетевой коммуникации, то на получение данных потерь практически нет, а вот на передачу все происходит процентов на 10 медленнее. Результат для 1 Гбит сети:

Кстати, очевидно, что сетевой трафик именно самой сети FT максимальный, когда машина принимает много данных (их нужно синхронизировать на второй узел), когда же данные передаются там трафик намного меньше (машина их просто отдает, а синхронизировать нужно только сам процесс передачи и параметры канала).

Результат для 10 Гбит сети. Вот тут и происходит ситуация, когда канал на прием забивается FT-трафиком, как итог - прием происходит только на полосе 2,4 Гбит:

Из-за необходимости поддержки параметров сетевой передачи и приема в синхронном режиме возникает Latency около 6 миллисекунд:

3. Тестирование подсистемы ввода-вывода.

Для тестирования работы с хранилищами (I/O) взяли стандартный инструмент IOMeter. Особых потерь не обнаружилось:

4. Тест Swingbench для Oracle 11g.

Для теста была взята OLTP-нагрузка на базу данных. По числу транзакций в секунду потери небольшие, но задержка по времени ответа возникает значительная:

5. Тест DVD Store на Microsoft SQL Server 2012.

Здесь была запущена симуляция 64 пользовательских сессий. По-сути, этот тест очень похож на методику для Oracle, ну и результаты здесь также соответствующие (но по времени отклика как-то все очень печально):

6. Бенчмарк на базе TPC-E.

Здесь были симулированы операции сервера брокерской компании, который производит обработку OLTP-транзакций в реальном времени. Тест очень стрессовый, и потери здесь весьма существенны:

7. Операции VMware vCenter Server.

Ну а здесь уже сам сервер vCenter защитили технологией Fault Tolerance и измерили производительность операций для двух типов нагрузки - легкой и тяжелой. При тяжелой нагрузке все происходит медленнее больше чем в 2 раза:

vSphere Web Client работает, в общем-то, неплохо, но хотелось бы лучше:

Результаты тестирования очень полезны - теперь администраторы смогут закладывать потери производительности на поддержание FT-кластера в архитектуру планируемой инфраструктуры для бизнес-критичных приложений.

Компания VMware на днях опубликовала пресс-релиз с квартальным и годовым отчетом за 4-й квартал 2015 года и весь 2015 год, соответственно. Напомним, что о прошлом отчете мы писали вот тут, а финансовые отчеты за все прошлые года доступны тут.

Давайте посмотрим на результаты 2015 года в сравнении с результатами 2014:

Интересны также 3 вывода из пресс-релиза:

• Решения VMware в области End-User Computing растут на 30% в год, и сейчас сумма заказов за год составляет 1,2 миллиарда долларов.
• В 2015 году бизнес по продаже решения для виртуализации сети датацентра VMware NSX вырос в 2 раза и составляет $600 миллионов.
• Если брать в расчет 4-й квартал 2015 года, то бизнес по продаже решения VMware Virtual SAN вырос в 3 раза, а сумма заказов достигла 100 миллионов долларов.

Пока компания продолжает расти и наращивать активы, вроде бы все хорошо. Но. В целях повышения операционной эффективности компания VMware планирует уволить 800 человек (в отчете это скрывается за мягким выражением "restructuring and realignment"), а это уже первая ласточка насытившегося рынка.

Также вот тут пишут, что команды VMware Workstation и VMware Fusion полностью уволены. Это подтверждается вот этим постом теперь уже бывшего сотрудника VMware. На данный момент не очень понятно, что будет с самими продуктами. Хотя, как они могут продолжить жить без команд их разрабатывающих?

Всем интересующимся технологиями виртуализации интересно, что же нового готовит компания VMware в своей продуктовой линейке в 2016 году. Специально для вас компания VMware проводит серию онлайн-мероприятий под названием "Enabling the Digital Enterprise", где будут озвучены основные технологические направления виртуализационного гиганта.

Программа мероприятия разбита на треки, посвященные основным направлениям деятельности компании:

Track 1 – Deliver and Secure Your Digital Workspace

Здесь, очевидно, речь пойдет о доставке пользовательских окружений и защите решений в сфере виртуализации приложений и настольных ПК. Попросту говоря, будет рассказано о том, что нового появится в линейке VMware Horizon. Мероприятие пройдет по регионам:

• Americas Tuesday, February 9 at 9:30 AM PST
• EMEA Wednesday, February 10 at 9:30 AM GMT
• Asia Pacific Tuesday, February 16 at 9:00 AM (GMT +11)

Track 2 – Build and Manage Your Hybrid Cloud

Тут уже речь пойдет о построении гибридного облака с помощью решений VMware. То есть, с одной стороны, будут рассказывать о развитии онпремизной серверной линейки продуктов, построенных на платформе VMware vSphere, а с другой стороны, речь пойдет об использовании облачных решений на базе публичного облака VMware vCloud Air.

В рамках трека вам нужно будет выбрать направление cloud management platform (CMP) или hyper-converged infrastructure (HCI), хотя они не являются взаимоисключающими.

Анонс также будет разнесен по времени для различных регионов:

• Americas Wednesday, February 10 at 8:30 AM PST
• EMEA Thursday, February 11 at 9:30 AM GMT
• Asia Pacific Tuesday, February 16 at 9:00 AM (GMT +11)

Больше подробностей о мероприятии можно узнать по этой ссылке, там же можете и зарегистрироваться.

Интересная статья от Дункана Эппинга была опубликована в его блоге пару недель назад. Если вы хотите использовать виртуальные тома VVols, которые обладают некоторыми преимуществами по сравнению с традиционной файловой системой VMware VMFS, то для некоторых систем, поддерживающих механизм VASA (vSphere API for Storage Awareness), потребуется использовать внешний виртуальный модуль VASA Vendor Provider (VP). То есть, некоторые аппаратные хранилища уже содержат в себе готовые модули и прошитые в них модули VP, а вот для некоторых нужно запускать и поддерживать специальную виртуальную машину, выполняющую сервисные функции при работе виртуальных машин с хранилищами VVols.

Прежде всего VP используется для выполнения операции Bind (привязка машины к VVol), которая инициируется при запуске виртуальной машины. В этом случае VP создает точку доступа ввода-вывода (IO access point) для виртуального тома VVol на выбранном Protocol Endpoint (PE). Без этой операции машина не запустится, из чего следует, что критически важно поддерживать виртуальную машину с VP непрерывно доступной. У разных вендоров используются разные уровни доступности:

• Кто-то выпускает модуль с возможностью active/standby или active/active-конфигурации виртуальных машин на разных хостах.
• Ну а кто-то надеется на встроенные механизмы обеспечения отказоустойчивости VMware HA и VMware Fault Tolerance (FT).

Очевидно, что если вы выбираете хранилище с внешним VP, то очень желательно, чтобы там был реализован первый вариант обеспечения доступности. Ну и нельзя помещать виртуальную машину с VASA VP на том VVol, чтобы не оказаться в ловушке невозможности запуска этой виртуальной машины.

Со временем VMware планирует включить операции bind/unbind в стандарт T10 SCSI, и сервисная виртуальная машина будет не нужна, но эти вещи, как вы понимаете, делаются не быстро, поэтому пока обеспечивайте отказоустойчивость виртуальных модулей VP, по крайней мере, с помощью технологий VMware HA и VMware Fault Tolerance.

И да, в комментарии пишут, что у одного админа получилось так, что машина с VP просто перестала выполнять команды, хотя сама ВМ работала. В результате продуктивные ВМ было не запустить. Поэтому имеет смысл задуматься и об обеспечении отказоустойчивости на уровне компонентов VP (может, как-нибудь проверять скриптами его работоспособность?).

Когда вы ставите один сервер VMware ESXi, то проще всего сделать это, смонтировав ISO-образ через iLO или подобную консоль, либо воткнув загрузочную флешку непосредственно в сервер. Но если у вас несколько хост-серверов ESXi, то делать так уже несолидно для опытного администратора. В целях ускорения процесса он использует процедуру загрузки установщика хоста по сети через механизм PXE, а самые крутые администраторы уже используют средство Auto Deploy, у которого сравнительно недавно появился GUI.

На эту тему компания VMware выпустила очень полезный документ "Installing ESXi Using PXE", в котором эта процедура расписывается по шагам (как для BIOS, так и для UEFI-хостов):

Интересна диаграмма зрелости процесса установки VMware ESXi в организации. Новички прожигают исошку на диск, а крутые перцы - используют Auto Deploy для stateless-хостов:

А вот, например, основная диаграмма последовательности процессов при установке ESXi через PXE:

По шагам процедура выглядит так:

1. Администратор загружает целевой хост ESXi.

2. Этот хост делает DHCP-запрос.

3. DHCP-сервер отвечает с IP-параметрами и расположением TFTP-сервера, который содержит загрузчик.

4. ESXi обращается к серверу TFTP и запрашивает файл загрузчика, который указал DHCP-сервер.

5. TFTP-сервер посылает загрузчик хосту ESXi, который исполняет его. Начальный загрузчик догружает дополнительные компоненты с TFTP-сервера.

6. Загрузчик ищет конфигурационный файл на TFTP-сервере, скачивает ядро и другие компоненты ESXi с HTTP-сервера, который размещен на TFTP-сервере, и запускает ядро на хосте ESXi.

7. Установщик ESXi запускается в интерактивном режиме, либо используя kickstart-скрипт, который указан в конфигурационном файле.

Для автоматизации задач по подготовке ISO-образа ESXi к загрузке через PXE вы можете использовать вот этот полезный скрипт.

Идею для моей очередной функции Get-VMHostBirthday я позаимствовал из статьи известного блогера Магнуса Андерссона (Magnus Andersson), который задался интересным вопросом: «Как узнать дату и время установки хоста ESXi?». Вопрос, как оказалось, не такой уж простой, но решение, предложенное автором, мне показалось чересчур сложным по отношению к цене вопроса.

Компания RightScale, разрабатывающая ПО в сфере универсального управления облачными инфраструктурами, зарелизила ресурс http://cloudcomparison.rightscale.com, на котором можно сравнить основные публичные облачные платформы и изучить их функциональные возможности:

На данный момент на сайте присутствуют только 4 публичных облака: Amazon AWS, Google Cloud Platform, Microsoft Azure и SoftLayer от IBM. Интересно, что с помощью фильтров слева можно узнать, какие гостевые ОС доступны, в каких странах доступен сервис, а также что облако предлагает в плане вычислительных мощностей, хранилищ и сетевых возможностей.

Даже если с практической точки зрения это вам не интересно, все равно прикольно потыкать на галочки фильтров и посмотреть, какая из платформ что умеет. Из того, что я натыкал - AWS вне конкуренции.

Компания VMware на днях выпустила новую версию своего главного средства для P2V-переноса физических серверов в виртуальную среду vCenter Converter Standalone 6.1. Напомним, что о прошлой версии Converter, которая вышла весной прошлого года, мы писали вот тут.

Посмотрим на новые возможности Converter:

• Поддержка новых гостевых ОС для переноса физических систем на базе Windows 10 и Ubuntu 15.
• Возможность офлайн-конвертации виртуальных машин с платформы Microsoft Hyper-V 2012 R2 на Workstation и vSphere.
• Аутентификация на базе ключа по SSH для исходных физических Linux-систем при P2V-миграции.
• Поддержка настольной платформы виртуализации VMware Workstation 12.

Скачать VMware vCenter Converter Standalone 6.1 можно по этой ссылке. Release notes по продукту (включая список поддерживаемых продуктов и гостевых ОС) доступны тут.

Представляем вам гостевой пост от облачного сервиса 1cloud, регулярно рассказывающего на страницах нашего сайта о перспективных технологиях. Одной из наиболее активно обсуждаемых тем уходящего года стала «революция контейнеров» — многие компании внедряют их в свою инфраструктуру, а вендоры создают новые технологии для работы с ними. Недавно мы рассказывали о новых разработках VMware в этой области, а теперь представляем вашему вниманию адаптированный перевод заметки инженера компании о сложностях и мифах, связанных с контейнерами.

Вы стали свидетелями одного из самых крупных сдвигов, произошедших в IT-индустрии. Пятнадцать лет тому назад вы могли себе представить, что буквально одним нажатием кнопки сможете перенести приложение из одной части функционирующего дата-центра в другую, не создав при этом неудобств пользователям?

VMware сделала возможным переход от аппаратного обеспечения к программному, от ручного управления к автоматизации. Используя контейнеры, старую технологию, которую упростили такие компании, как Docker и CoreOS, мы можем мгновенно запустить множество приложений на общем ядре. В ноябре 2015 года в Барселоне прошла конференция Dockercon Europe 2015, посвященная безопасности, пользовательскому интерфейсу, RBAC-авторизации и эксплуатации программного обеспечения в целом. Стоит только упомянуть эти термины, как все внимание крупных организаций тут же обратится на вас.

На конференции искали способы заполнения пропасти между разработчиками (которые любят Docker) и IT-специалистами (у которых есть и другие проблемы, которые нужно решать). Объединить задачи этих групп спеиалистов и пытается VMware, компания тратит много усилий на популяризацию технологии контейнеров. Работа ведется по нескольким фронтам: создаются инструменты и внедряются технологии, способные облегчить этот переход.

Технология контейнеров быстро стала популярной среди разработчиков, поскольку с её помощью можно легко управлять сложными распределенными и переносимыми архитектурами приложений. Именно гибкость, переносимость и простота сделали контейнеры отличным решением для создания новых приложений. Однако с большими возможностями приходит большая ответственность – необходимо решить проблемы управления и эксплуатации, полностью понять новую парадигму разработки. Давайте рассмотрим наиболее частые заблуждения о контейнерной технологии, прежде чем вы продолжите с ней знакомство. Читать статью далее->>

Вчера мы писали про режим воспроизведения, который можно использовать для утилиты esxtop, предназначенной мониторинга производительности хост-серверов VMware ESXi. А сегодня предлагаем вам скачать постер "vSphere 6 ESXTOP quick Overview for Troubleshooting", в котором приведена основная информация для начала работы с esxtop, а также базовые приемы по решению возникающих в виртуальной инфраструктуре проблем с производительностью. Также стоит заглянуть вот в эту и эту заметку на нашем сайте.

Постер можно повесить в админской или серверной, где часто приходится работать с консолью серверов ESXi:

Интересную новость мы обнаружили вот тут. Оказывается утилита esxtop может работать в режиме повтора для визуализации данных о производительности, собранных в определенный период времени (многие администраторы знают это, но далеко не все). Это позволит вам собрать данные о производительности хоста, например, ночью, а в течение рабочего дня проанализировать аномальное поведение виртуальной инфраструктуры VMware vSphere. Называется этот режим replay mode.

Для начала запустите следующую команду для сбора данных на хосте VMware ESXi:

# vm-support -p -d 120 -i 10 -w /vmfs/volumes/your_datastore

Объяснение параметров:

• -p - собирать только данные о производительности is to only gather performance data
• -d - длительность сбора (здесь 120 секунд)
• -i - интервал сбора данных (тут раз в 10 секунд)
• -w - хранилище куда положить выходной файл

Файл по умолчанию создается сжатым, поэтому разжимаем его следующей командой:

# tar -xzf filename.tgz

Запускаем режим воспроизведения данных следующей командой:

# esxtop -R extracted_content_file_name

И вот видим привычный нам вывод esxtop, который будет обновляться с указанным при записи данных интервалом:

Если при запуске esxtop replay mode вы получите ошибку такого вида:

No such file or directory esxtop […] all vm-support snapshots have been used

То просто запустите предварительно скрипт reconstruct.sh, который будет находиться в папке с разархивированным содержимым после отработки tar:

# ./reconstruct.sh

Мы часто пишем о том, что снапшоты в VMware vSphere - это плохо (за исключением случаев, когда они используются для горячего резервного копирования виртуальных машин и временного сохранения конфигурации ВМ перед обновлением).

Однако их использование в крупных инфраструктурах неизбежно. Рано или поздно возникает необходимость удаления/консолидации снапшотов виртуальной машины (кнопка Delete All в Snapshot Manager), а процесс этот достаточно длительный и требовательный к производительности хранилищ, поэтому неплохо бы заранее знать, сколько он займет.

Напомним, что инициирование удаления снапшотов в vSphere Client через функцию Delete All приводит к их удалению из GUI сразу же, но на хранилище процесс идет долгое время. Но если в процесс удаления возникнет ошибка, то файлы снапшотов могут остаться на хранилище. Тогда нужно воспользоваться функцией консолидации снапшотов (пункт контекстного меню Consolidate):

О процессе консолидации снапшотов мы также писали вот тут. Удаление снапшотов (как по кнопке Delete All, так и через функцию Consolidate) называется консолидацией.

Сначала посмотрим, какие факторы влияют на время процесса консолидации снапшотов виртуальной машины:

• Размер дельта-дисков - самый важный параметр, это очевидно. Чем больше данных в дельта-диске, тем дольше их нужно применять к основному (базовому) диску.
• Количество снапшотов (число дельта-файлов) и их размеры. Чем больше снапшотов, тем больше метаданных для анализа перед консолидацией. Кроме того, при нескольких снапшотах консолидация происходит в несколько этапов.
• Производительность подсистемы хранения, включая FC-фабрику, Storage Processor'ы хранилищ, LUN'ы (число дисков в группе, тип RAID и многое другое).
• Тип данных в файлах снапшотов (нули или случайные данные).
• Нагрузка на хост-сервер ESXi при снятии снапшота.
• Нагрузка виртуальной машины на подсистему хранения в процессе консолидации. Например, почтовый сервер, работающий на полную мощность, может очень долго находится в процессе консолидации снапшотов.

Тут надо отметить, что процесс консолидации - это очень требовательный к подсистеме ввода-вывода процесс, поэтому не рекомендуется делать это в рабочие часы, когда производственные виртуальные машины нагружены.

Итак, как можно оценивать производительность процесса консолидации снапшотов:

Смотрим на производительность ввода-вывода хранилища, где находится ВМ со снапшотами.

Для реализации этого способа нужно, чтобы на хранилище осталась только одна тестовая виртуальная машина со снапшотами. С помощью vMotion/Storage vMotion остальные машины можно с него временно убрать.

1. Сначала смотрим размер файлов снапшотов через Datastore Browser или с помощью следующей команды:

ls -lh /vmfs/volumes/DATASTORE_NAME/VM_NAME | grep -E "delta|sparse"

2. Суммируем размер файлов снапшотов и записываем. Далее находим LUN, где размещена наша виртуальная машина, которую мы будем тестировать (подробнее об этом тут).

3. Запускаем команду мониторинга производительности:

# esxtop

4. Нажимаем клавишу <u> для переключения в представление производительности дисковых устройств. Для просмотра полного имени устройства нажмите Shift + L и введите 36.

5. Найдите устройство, на котором размещен датастор с виртуальной машиной и отслеживайте параметры в колонках MBREAD/s и MBWRTN/s в процессе консолидации снапшотов. Для того, чтобы нужное устройство было вверху экрана, можно отсортировать вывод по параметру MBREAD/s (нажмите клавишу R) or MBWRTN/s (нажмите T).

Таким образом, зная ваши параметры производительности чтения/записи, а также размер снапшотов и время консолидации тестового примера - вы сможете оценить время консолидации снапшотов для других виртуальных машин (правда, только примерно того же профиля нагрузки на дисковую подсистему).

Смотрим на производительность конкретного процесса консолидации снапшотов.

Это более тонкий процесс, который можно использовать для оценки времени снапшота путем мониторинга самого процесса vmx, реализующего операции со снапшотом в памяти сервера.

1. Запускаем команду мониторинга производительности:

# esxtop

2. Нажимаем Shift + V, чтобы увидеть только запущенные виртуальные машины.

3. Находим ВМ, на которой идет консолидация.

4. Нажимаем клавишу <e> для раскрытия списка.

5. Вводим Group World ID (это значение в колонке GID).

6. Запоминаем World ID (для ESXi 5.x процесс называется vmx-SnapshotVMX, для ранних версий SnapshotVMXCombiner).

7. Нажимаем <u> для отображения статистики дискового устройства.

8. Нажимаем <e>, чтобы раскрыть список и ввести устройство, на которое пишет процесс консолидации VMX. Что-то вроде naa.xxx.

9. Смотрим за процессом по World ID из пункта 6. Можно сортировать вывод по параметрам MBREAD/s (клавиша R) или MBWRTN/s (клавиша T).

10. Отслеживаем среднее значение в колонке MBWRTN/s.

Это более точный метод оценки и его можно использовать даже при незначительной нагрузке на хранилище от других виртуальных машин.

Очередная функция Get-VMHostFirmwareVersion моего PowerCLI модуля для управления виртуальной инфраструктурой VMware Vi-Module.psm1 поможет вам узнать версию и дату выпуска Firmware ваших серверов ESXi. Для большей гибкости и удобства в использовании, функция написана в виде PowerShell-фильтра.

Не так давно на сайте VMwareArena появилось очередное сравнение VMware vSphere (в издании Enterprise Plus) и Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition, которое включает в себя самую актуальную информацию о возможностях обеих платформ.

Мы адаптировали это сравнение в виде таблицы и представляем вашему вниманию ниже:

Подводя итог, скажем, что нужно смотреть не только на состав функций той или иной платформы виртуализации, но и необходимо изучить, как именно эти функции реализованы, так как не всегда реализация какой-то возможности позволит вам использовать ее в производственной среде ввиду различных ограничений. Кроме того, обязательно нужно смотреть, какие функции предоставляются другими продуктами от данного вендора, и способны ли они дополнить отсутствующие возможности (а также сколько это стоит). В общем, как всегда - дьявол в деталях.

Компания VMware выпустила первое после нового года обновление своей серверной платформы виртуализации - VMware vSphere 6.0 Update 1b, включая обновления vCenter и ESXi.

Новых возможностей, конечно же, немного, но все же компоненты vSphere рекомендуется обновить ввиду наличия критичных обновлений подсистемы безопасности.

Что нового в VMware vCenter Server 6.0 Update 1b:

• Поддержка метода обновления URL-based patching с использованием zip-пакета. Подробнее в KB 2142009.
• Пользовательские настройки для Client Integration Plugin или диалогового окна VMware-csd guard в vSphere Web Client могут быть переопределены. Подробнее в KB 2142218.
• vSphere 6.0 Update 1b включает поддержку TLS версий 1.1 и 1.2 для большинства компонентов vSphere без нарушения совместимости с предыдущими версиями. Компоненты которые по-прежнему поддерживают только TLS версии 1.0:
  • vSphere Client
  • Virtual SAN Observer на сервере vCenter Server Appliance (vCSA)
  • Syslog на сервере vCSA
  • Auto Deploy на vCSA
  • Auto Deploy на iPXE
  О поддержке TLS-протоколов можно почитать подробнее в KB 2136185 .
• Утилита certificate manager теперь автоматически вызывает скрипт updateExtensionCertInVC.py для обновления хранилищ сертификатов, которые построены не на базе VMware Endpoint Certificate Store (VECS).
• Множество исправлений ошибок.

Что нового в VMware ESXi 6.0 Update 1b:

• Поддержка TLS версий 1.1 и 1.2 для большинства компонентов без нарушения совместимости с предыдущими версиями.
• Поддержка Advanced Encryption Standard (AES) с длиной ключа 128/256 бит для аутентификации через NFS 4.1 Client.
• Исправления ошибок.

Скачать VMware vCenter Server 6.0 Update 1b и VMware ESXi 6.0 Update 1b можно по этой ссылке.

Это гостевой пост сервис-провайдера 1cloud, предоставляющего услуги облачной аренды виртуальных машин. Ранее они рассказывали о развитии данной технологии в статье о «революции контейнеров» в своем блоге на Хабре.

Шумиха вокруг контейнеров последнего времени поставила один важный вопрос: как эта технология сможет ужиться с традиционными вариантами управления инфраструктурой, и какие угрозы она таит для рынка виртуализации? И даже более конкретный: заменят ли контейнеры виртуальные машины?

На ежегодной конференции в Сан-Франциско, прошедшей на в сентябре 2015 года, VMware дала однозначно понять, что этого не произойдет. Новая платформа управления вводит новый тип виртуализации — для самих контейнеров.

Виртуализация для контейнеров

«В ее основе, по-прежнему, лежит принцип виртуализации», — объясняет вице-президент VMware и технический директор Cloud Native Applications Кит Колберт. Он предпочитает называть Photon «микровизором» с достаточным набором функций для успешной виртуализации, упакованный в удобный для контейнеров формат.

Project Photon состоит из двух ключевых элементов. Photon Machine – оболочка для гипервизора, дублирующая ESX и устанавливаемая напрямую на физические серверы. Она создает виртуальную машину в миниатюре, куда помещаются контейнеры. Пользователь может самостоятельно выбрать гостевую ОС. По умолчанию устанавливается Photon ОС под Linux, которую компания также сделала совместимой с технологией контейнеров.

Второй элемент – это Photon Controller, мультитенантный маршрутизатор, позволяющий управлять одновременно дюжинами, если не тысячами, объектов на Photon Machine. Он следит за тем, чтобы все блоки (кластеры) Photon Machine имели доступ к сети и базам данных, когда это необходимо.

Комбинация этих двух элементов задает шаблон для масштабируемой среды и имеет надстройку для написания API. В теории, IT-операторы могу усовершенствовать Project Photon, и сами разработчики создавать на его базе приложения.

Project Photon способен интегрироваться с открытыми программами. Например, с Docker’ом для поддержки исполнения программы, или с Google Kubernetes и Pivotil’s Cloud Foundry для более качественного управления приложениями. Photon в данном случае выполняет подготовку инфраструктуры, а Kubernetes и CF занимаются развертыванием приложений.

В прошлом году для индивидуальных пользователей платформа стала доступна в качестве бета-версии.

Долгая дорога к контейнерам

Не все пользователи готовы полностью переключиться на контейнерную реализацию. Поэтому VMware для сомневающихся интегрирует поддержку контейнеров с традиционными инструментами управления.

vSphere Integrated Containers – еще один продукт, анонсированный на конференции. Как пояснил Кит Колберт, это идеальный вариант для тех, кто только хочет начать экспериментировать с контейнерами. Для желающих же использовать возможности контейнеров по максимуму он рекомендует переход к Project Photon.

vSphere Integrated Containers представляет собой плагин для vSphere, установленной на достопочтенном ESX компании. «Он делает контейнеры самыми желанными гостями платформы», — уточняет Колберт. При помощи плагина пользователи могут устанавливать контейнеры внутрь виртуальной машины, позволяя управлять ею так же, как и любой другой в пространстве платформы виртуализации.

В текущих условиях, если пользователь решил загрузить контейнеры в vSphere, ему приходится все скопом помещать их в одну единственную виртуальную машину. Таким образом, если что-то случится с одним из контейнеров, повреждения могут получить и все остальные, находящиеся в ВМ. Распределение контейнеров по разным ВМ обеспечивает их сохранность и аккуратное управление платформой.

Аналитик Marko Insights Курт Марко говорит, что новый подход к контейнерной реализации VMware должен облегчить жизнь и самим администраторам платформы. «Работа с контейнерами Photon в формате микро-ВМ схожа с тем, как работают с классом стеков и операторов, — сообщает Марко в своем письме. – Конечно, здесь могут быть потери в производительности, поскольку даже микро-ВМ будут больше перегружены, чем контейнеры, пользующиеся одними ядрами и библиотеками. В самой VMware утверждает, что это проблемой можно пренебречь, но Марко настаивает на независимом анализе издержек работы с контейнерами внутри виртуальных машин.

Не все так быстро

В VMware полны энтузиазма и рассматривают себя в качестве флагмана контейнерной реализации. Но есть несколько моментов, способных этот порыв охладить. Во-первых, вероятно, рынок контейнеров еще к этому не готов.

«Реклама продукта пока обгоняет реальность», — говорит аналитик IDC Эл Гиллен. По его подсчетам, менее десятой доли процента корпоративных приложений сейчас делаются через контейнеры. Может пройти десятилетие, пока рынок переварит эти технологии, и цифра приблизится к 40%.

Во-вторых, VMware никогда не обладала репутацией компании, готовой быть в авангарде разработок открытого программного обеспечения и проектов. Скорее, наоборот. Соучредитель и исполнительный директор Rancher Labs (стартапа, внедрившего свою ОС для контейнеров на VMworld) Шен Льян говорит, что до этого момента контейнерную реализацию продвигали сами разработчики или открытые платформы, наподобие Mesos, Docker и Kubernetes. Он добавил, что не встречал еще ни одного человека, использующего в работе контейнеры, который бы делал это с помощью инструментария VMware.

Аналитик Forrester Дейв Бартолти не удивлен данному обстоятельству. В VMware налажены прочные связи с проектными ИТ-менеджерами, но не с разработчиками, активно использующими контейнеры. Новинки, которые компания представила на VMworld, должны как раз вдохновить первых активно использовать контейнеры в рамках работы с платформой VMware. Остальные вендоры, среди которых Red Hat, Microsoft и IBM, также с удовольствием пользуются этой процедурой. VMware настаивает, что нашла способ примерить виртуальные машины и контейнеры.

Как вы знаете, в новой версии решения VMware Horizon 6.2 для виртуализации настольных ПК компания VMware сделала специальное издание VMware Horizon for Linux, позволяющее создавать инфраструктуру виртуальных десктопов на базе компьютеров с хостовой ОС Linux. Это востребовано в организациях, где такие рабочие станции используются для графического моделирования, сложных расчетов и прочих требовательных к производительности графической подсистемы нагрузок.

Напомним, что еще с версии Horizon 6.2 полностью поддерживались режимы Virtual Shared Graphics Acceleration (vSGA), Virtual Dedicated Graphics Acceleration (vDGA) и NVIDIA GRID vGPU на базе GRID 2.0 для Linux-десктопов:

Совсем недавно компания VMware выпустила VMware Horizon 6.2.1, где в плане поддержки Linux-десктопов появилось еще несколько нужных новых возможностей:

1. Clipboard Redirection (Copy / Paste).

Теперь в Linux-десктопах появилось перенаправление клавиатуры, которое позволяет копировать и вставлять из хостового ПК в виртуальный и обратно текст с форматированием, а также картинки. Естественно, в целях безопасности можно эту функцию отключить в файле конфигурации /etc/vmware/config (см. документ "Setting Up Horizon 6 for Linux Desktops").

2. Single Sign-On.

Теперь в Linux-ПК появилась поддержка SSO, позволяющая пользователю хостового устройства не вводить учетные данные при логине в свой виртуальный ПК Linux, который интегрирован со службами Active Directory через Open LDAP. Эти возможности поддерживаются для Horizon Client под Mac, Windows и Linux. На данный момент функция доступна только для ПК Red Hat Enterprise Linux 6.6 Workstation x86_64 и CentOS 6.6 x86_64.

3. Smart Card Authentication.

Аутентификация через смарт-карты в виртуальном ПК требуется во многих государственных и частных организациях с соответствующими регулирующими процедурами. Для аутентификации поддерживаются карты типа Personal Identity Verification (PIV) и Common Access Cards (CAC) с дистрибутивом Red Hat Enterprise Linux 6.6 Workstation x86_64.

4. Kerberos Authentication

После установки View Agent в виртуальный ПК Linux вы можете выбрать тип аутентификации Kerberos в дополнение к уже имеющейся MD5 digest authentication.

5. Consolidated Client Environment Information

До VMware Horizon 6.2.1 вся информация о пользовательском окружении (имя хоста, IP-адрес и прочее) записывалась в стандартный лог-файл, содержащий отладочную информацию. Это было неудобно, так как файл большой, и выуживать из него нужные данные было тяжело. Теперь для этого есть отдельный файл /var/log/vmware/Environment.txt, который поможет решать проблемы при настройке инфраструктуры виртуальных ПК.

Получить VMware Horizon 6.2.1 for Linux можно двумя способами:

1. Купить лицензию VMware Horizon 6 Enterprise Edition, которая содержит все необходимое для построения VDI-инфраструктуры, в том числе на Linux-платформе.

2. Использовать специализированное издание Horizon 6 for Linux standalone, которое можно скачать по этой ссылке.

Иногда системному администратору VMware vSphere требуется узнать, сколько тот или иной хост ESXi работает с момента последней загрузки (например, требуется проверить, не было ли внеплановых ребутов).

Есть аж целых 5 способов сделать это, каждый из них можно применять в зависимости от ситуации.

1. Самый простой - команда uptime.

Просто заходим на хост ESXi из консоли или по SSH и выполняем команду uptime:

login as: root

  Using keyboard-interactive authentication.

  Password: XXXXXX

The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools.  Please

  see www.vmware.com/go/sysadmintools for details.
The ESXi Shell can be disabled by an administrative user. See the

  vSphere Security documentation for more information.

  ~ # uptime

  04:26:24 up 00:20:42, load average: 0.01, 0.01, 0.01

2. С помощью команды esxtop.

С помощью утилиты esxtop можно не только отслеживать производительность хоста в различных аспектах, но и узнать его аптайм. Обратите внимание на самую первую строчку вывода:

# esxtop

4. Время запуска хоста из лога vmksummary.log.

Вы можете посмотреть не только время текущего аптайма хоста ESXi, но времена его прошлых запусков в логе vmksummary.log. Для этого выполните следующую команду:

cat /var/log/vmksummary.log |grep booted

2015-06-26T06:25:27Z bootstop: Host has booted

  2015-06-26T06:47:23Z bootstop: Host has booted

  2015-06-26T06:58:19Z bootstop: Host has booted

  2015-06-26T07:05:26Z bootstop: Host has booted

  2015-06-26T07:09:50Z bootstop: Host has booted

  2015-07-08T05:32:17Z bootstop: Host has booted

4. Аптайм в vSphere Client и Web Client.

Если вы хотите вывести аптайм сразу всех виртуальных машин на хосте в VMware vSphere Client, для этого есть специальная колонка в представлении Hosts:

5. Аптайм хостов через PowerCLI.

Конечно же, время работы хоста ESXi можно посмотреть и через интерфейс PowerCLI. Для этого нужно воспользоваться командлетом Get-VMHost:

Get-VMHost | Get-View | select Name, @{N="Uptime"; E={(Get-Date) - $_.Summary.Runtime.BootTime}}|fl

Напомним, что до выполнения этой команды надо соединиться с хостом ESXi или vCenter:

Connect-VIServer -Server XXX.XXX.XXX.XXX -User YYYYYYY -Password ZZZZZZZZ

Недавно известный многим блоггер Frank Denneman выпустил бесплатную книгу "Designing A Storage Performance Platform":

В новой книге Фрэнка на 300 страницах раскрываются следующие моменты, касающиеся производительности подсистемы хранения платформ виртуализации, построенной на базе локальных дисков хост-серверов:

• Новая парадигма построения виртуального датацентра с точки зрения систем хранения
• Архитектура решения FVP
• Ускорение доступа к данным
• Технология непрерывной доступности Fault Tolerance
• Технология Flash
• Техники доступа к памяти
• Настройка кластера решения FVP
• Сетевой дизайн инфраструктуры локальных хранилищ
• Внедрение и пробная версия решения FVP
• Дизайн инфраструктуры хранилищ

Несмотря на то, что книга рассматривает в качестве основного продукта решение FVP от компании PernixData, ее интересно читать и с точки зрения понимания архитектуры и производительности подобных решений.

От лица всего коллектива VM Guru, его авторов и волонтеров, поздравляю наших читателей и партнеров с Новым 2016 годом! В следующем году желаю вам бывать больше с семьей, найти и сохранить любовь, достичь профессиональных успехов и осуществить, по крайней мере, одну большую мечту!

Все вам самого доброго и теплого в новом году! Пусть все невзгоды и плохие люди обойдут вас стороной. Оставайтесь с нами - в следующем году у нас будет много интересного. Спасибо, что читаете нас.

Главный редактор VM Guru, Александр Самойленко.

Компания VMware выпустила интересную инфографику, наглядно представляющую распреление сертифицированных специалистов VMware Certified Professionals (VCP) по регионам мира. 70% стран мира имеют хотя бы одного VCP, а в 46% стран их больше, чем 50 (картинка кликабельна):

Интересно также и то, что 38% VCP имеют более, чем одну сертификацию (видимо, имеется в виду сертификация именно VMware).

Судя по всему, у нас VCP почти столько же, сколько, например, в ЮАР. Это прискорбно - посмотрите на Индию или Австралию, к примеру, и оцените разницу в масштабах.

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):